Warning this Friday facts is about the Introduction scenario, not about anything that will be in Freeplay Factorio. You may want to read previous FFFs (FFF-257, FFF-284) about the Introduction. TLDR: the Stable candidate of the Introduction scenario is now in Experimental please play it and send me your screenshots. Feedback especially on the “freeform endgame” would be greatly appreciated. We have also released a Experimental version of the Demo, be sure to send this link to your friends ASAP. SPOILER WARNING: If you have not yet played the Introduction Scenario, go play it before you read this.

Hello, the 0.15 has been declared stable. Unfortunately we found some smaller problems, so there is going to be at least one bugfix release. One of the problems we discovered yesterday, is a glitch in the blueprint transferring logic that results in the transfers stopping forever when a player that is just transferring his blueprint into the game leaves. I'm quite surprised that I found it out myself when I was testing something else, and we didn't have a single bug report regarding it.

Hey guys, here comes the weekly dose of Factorio-world information for you. We have crafted it just before we leave for a gdsession warm-up party. Gdsession is quite a big game development conference here in Prague. This is the first year we are going to participate. And actually tonight we will have a short (10 minutes) talk about what we do (well, about Factorio obviously).

Hello, Today we're going to take a look at a feature some of us have dreamt of changing for years now - the beacon transmission. The main purpose of beacons is to allow massively increasing your production in the late game while being more than just a module or a faster machine. To make use of beacons you need to adjust your building layout for them. Beacons succeed in this role, but...

Hello, it has been quiet here the last week, Rseding is back in America, Albert is in Spain, and some people have holidays. I have been programming until 9:30pm and then I realized I have to write Friday Facts, so it is going to be shorter today, although this happens quite often to me.

Hello, after a long long time the 0.9.8 was marked stable this week. There were no big ovations or cheering, just a quite "stable sticker exchange":) The bugs forum is not empty though, as someone would expect. Quite a few small issues remain, but for the sake of moving on we decided to put them to our backlog and mark the release as stable. However if some game crashing or very serious bugs are discovered in 0.9.8, we will make a hotfix. Oh, and the good thing is that we managed to break the streak (for now) of ever increasing number of bugfix releases (the 0.9 had 8 bugfix releases - the same as 0.8). The whole "programming department" has been fully commited to the work on multiplayer for a while now. The task divison for now is following: Michal - fully deterministic simulation. This is an absolute must, because all multiplayer peers will calculate the simulation themselves and only the player input (we call it input actions) will be exchanged over the network. Nice effect of having deterministic simulation will be having functional replays again (hmmm not really again because there have always been some bugs in them even when they were "working":)). Kuba - lower level network layer. This includes the connection management, packets management (we will be using UDP for all the communication) and eventually things like NAT punching to allow connections for peers behind NAT (few people have public IP address). Tomas - synchronization layer. This logic will take care of keeping the simulation state same for all the players in the game. This includes queing up the input actions, sending them out in batches (tick closures to other peers), requesting missing tick closures, etc. These things are absolute minimum necessary for our multiplayer implementation. However there is more to be done after this, things like: starting the game (the lobby), mechanism for a player joining already existing game, hiding the latency for the player (most of the time the actions for different players will not collide so we can act as if common actions - like moving the player around - were confirmed immediately) and more (see our battleplan whiteboard in one of the previous friday facts). There is a lot of work ahead, but the good news is that we have finally fully dived into it. We will keep you updated about the progress:) Albert has finished with most of the map trailer tweaks. Today we also did a first test with exporting the trailer using the new screenshot mechanism. We did this on Michal's computer which is way more powerful than mine (it does take a while to export 3600 screenshots). However there was this funky bug that parts of the terrain in the screenshots had strange, kind of inverted, colors. We have spent like half a day looking into this issue. Finally it turned out to be a problem in our custom optimized version of d3d drawing routine (this was happening on windows only). Spending hours in frustration hunting bugs (that are not even visible to the player in the end) happens more often than you would think, so game programming is not just about sitting back, playing video games and calling it "research" (but that is part of the job too:)) Anyway to give you an idea of what was going on you can see a visualization of the problem below. For better effect (and for us to easier analyze the problem) the corrupted regions of the image (here all of the terrain) are drawn with reddish overlay. Any idea for the picture title? Want to cheer us up for the multiplayer work? Or feel like laughing at us for taking so long with the trailer? Go to our forums.

With most of the team away for Gamescom or vacation, I have the pleasure of writing a Friday Facts for you this week.

New test servers We recently bought and assembled some high-end PCs, with the hope to gauge performance, speed up running tests, and potentially consolidate the number of servers we are maintaining internally. The two lucky CPUs were a i9-9980XE 18-core and a Ryzen 3900X 12-core. We are using the time to complete our test suite in 'heavy mode' as a benchmark. Heavy mode basically saves and reloads the game each tick, and compares a CRC of the map from before and after. It is super slow to run, but the heavy test is critical to help find any possible determinism issues. There is some more info on 'heavy mode' in FFF-63. As a baseline, the 'standard' CPU in the office for developers is the i9-7900x 10-core, which runs heavy tests in about 530 seconds. In real time this is 8 minutes and 50 seconds, a long time for a team member to sit around for results before they can push. We can do better! As you would expect, the new 18-core was blazing fast, with a test time of about 400 seconds, shaving off over 2 minutes. However the Ryzen was a different story, with a test time of about 600 seconds. This goes against what we predicted, where more cores and higher frequency mean lower test times. The initial results from the 12-core Ryzen were worse than from the 10-core Intel; not a good start. So I did some digging and some research, and the answer I arrived at was RAM. When we ordered the parts, not much thought was given to the selection of RAM, just some standard 16GB 2666MHz sticks to fill all the slots. Luckily, I looked on a local Czech website, and they had some stock of the brand new G.SKILL 3600MHz Trident RGB Neo, a high performance RAM stick made exactly to suit our new Ryzen CPU. After installing the new RAM, we had a test result that better matched our expectations: 450 seconds. We knew beforehand that Ryzen liked fast RAM, but we didn't realize how significant of a difference it could make. So now we have set up both these new machines to run tests automatically after each commit, and we are very happy with the result. The new i9-9980XE can compile and run heavy tests faster than our old i7-4790K can compile and run just normal tests. Having it run automatically also frees up individual developers from the responsibility of running heavy tests locally, so they can just push as normal and continue working.

Hello, It has been a month since the Space Age release and things are settling into a steady state. It is a good time to wrap things up, and discuss our future plans.

Combat Balance Twinsen here. As you might have read in Friday Facts #166, we wanted to do some combat balancing. First, to not bring the hopes of everyone up too much, this did not mean a combat overhaul. It means mostly tweaking numbers to make the game more fun and make some of the the weapons more viable. No new entities or new mechanics. As I was doing the combat balance, it was clear the everyone has their own different opinion of how combat is, how it should be and how to make it "better". It's hard to please everyone, especially when you are just tweaking numbers. To try to objectively evaluate combat I used the following methodology. As the game progresses, the player's power increases through research, but so do the biters(mainly due to evolution factor). So I split the game in 7 sections based on research progress. Each section also has the evolution factor I tested biters will approximately have in an average game. Initial - 0 evolution Red - 0.1 evolution Red+Green - 0.3 evolution Red+Green+Military - 0.4 evolution Red+Green+Blue+Military - 0.7 evolution Red+Green+Blue+Military+High Tech - 0.9 evolution Red+Green+Blue+Military+High Tech+Production - 0.99 evolution Then for each section I tested both offensive combat and defensive combat using the available guns and turrets and tweaked the numbers accordingly. While tweaking the numbers, I keep this in mind (this is not a complete list): Fun always wins: I prefer changes that are more fun and less annoying even if it means it could be slightly unbalanced. New weapons should be slightly more powerful than old weapons, to incentivize you to experiment. So near the end game, a rocket launcher will be better than the machine gun. Destroying biter bases is hard in the beginning and significantly easier toward the end game, to give the sense of combat power progression. Defending is not too hard in the beginning. I try not to put a new player in the situation of "you didn't prepare properly, you have to start a new game, because no matter what you do you will get killed". Then throughout the game you have to upgrade your defenses as the biters evolve. So far, the changelog looks like this. There are many numbers that were tweaked and are not included in this list. Player regains health at a much higher rate, but only after being out of combat for 10 seconds. Discharge defense equipment pushes back, stuns and damages nearby enemies when activated by the remote. Decreased the size of Discharge defense equipment from 3x3 to 2x2. Greatly increased the damage of Personal Laser Defense Equipment. Flamthrower gun has a minimum range of 3. The flames created on ground from the flamethrower significantly increase in duration and damage when more fuel is added to them by firing at the same spot. Increased fire resistance of biter bases. Increased the health of player non-combat buildings. Increased player health from 100 to 250. Increased collected amount and effectiveness of Raw Fish. Increased the damage, range and health of biters worms. Decreased health and resistance of Behemoth biters. Doubled the stack size of all ammos. Tweaked the cost and crafting time of some ammos. Increased the damage of most player ammos. Greatly increased the damage and fire rate of Rockets and Cannon Shells. Increased the collision box of Cannon Shells. Increased Tank health and resistances. Added research for Tank Cannon Shells damage and shooting speed. Tweaked research bonuses and added more end-game research for military upgrades. Greatly increased the damage of Mines. They also stun nearby enemies when they explode. Biters stop following player after 10 sec of not giving or receiving damage if the player is more than 50 tiles away. Other minor changes. As usual, these changes are not final and will probably change to some degree as we playtest more. There are still many things to be done. We are always talking about more end-game weapons, so don't worry, the combat in the late-game will be even more worry-free. There is also one thing that we always talked about trying to remove: turret-creep (destroying biters base building turrets closer and closer). This method is very powerful and usually doesn't cost anything. So far I believe that we did not find a simple, fun and fair solution. Ideas include: large power-up times(annoying and also weakens base defense); simply not allowing turrets to be build near biter bases (makes the player feel cheated); underground anti-turret worms (sugar-coated version of the previous idea). With the combat changes that were done I believe there is almost always an option to destroy bases without being forced to use turret-creep.In the end maybe your ingenuity and effort of building all those electric poles should be rewarded; If the player wants to do it that way, why not let him? Let us know what you think.